Systems and methods for api request conversion

ABSTRACT

A method or system for application program interface (API) request conversion, includes generating a plurality of configuration files, each associated with a different API format. A first API format of the first API request is identified and a first configuration file is identified based on the first API format. A second API request having a second API format is generated by applying the first API request to the first configuration file. A third API request is received and a third API format of the third API request is identified. A second configuration file is identified based on the third API format. A fourth API request is generated having the second API format by applying the third API request to the second configuration file.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims the benefit of priority as a continuationto U.S. Non-Provisional application Ser. No. 17/150,371, filed Jan. 15,2021, which claims the benefit of and priority to U.S. ProvisionalPatent Application No. 62/964,462, filed Jan. 22, 2020, the entirety ofeach of which is incorporated by reference herein.

BACKGROUND

The present disclosure relates generally to systems and methods forintegrating systems using different application programming interfacestructures (APIs). The present disclosure relates more particularly toconverting API requests in multiple formats to a common format.

The technological landscape of APIs is ever growing, forking,fragmenting, and recombining. While this provides users and developerswith a large number of choices when it comes to how and when tointerface with new systems, it can be difficult for the new systems tocommunicate or otherwise integrate with each other. In one example, tointerface or integrate between modern web-based systems, APIs are used.If a user is interested in integrating or allowing different systems tocommunicate with each other, the user may have to constantly update thecode to interface with the systems' APIs and formats thereof, which canbe considerably different. This can result in “code rot” in which codegradually deteriorates or becomes unusable over time due to the failureto adequately integrate with the different APIs or failure to keep upwith the updates of those APIs.

The above information disclosed in this Background section is forenhancement of understanding of the background of the disclosure, andtherefore, it can contain information that does not constitute priorart.

SUMMARY

Certain examples described herein relate to a method for applicationprogram interface (API) request conversion, including: generating, byone or more processors, a plurality of configuration files, eachconfiguration file associated with a different API format; receiving, bythe one or more processors, a first API request; identifying, by the oneor more processors, a first API format of the first API request; andidentifying, by the one or more processors, a first configuration fileof the plurality of configuration files based on the first API format.The method further includes generating, by the one or more processors, asecond API request having a second API format by applying the first APIrequest to the first configuration file. The method further includes:receiving, by the one or more processors, a third API request;identifying, by the one or more processors, a third API format of thethird API request; identifying, by the one or more processors, a secondconfiguration file of the plurality of configuration files based on thethird API format; and generating, by the one or more processors, afourth API request having the second API format by applying the thirdAPI request to the second configuration file to generate a fourth APIrequest having the second API format.

In further examples, the method further includes: identifying, by theone or more processors, an endpoint at which the first API request isdirected; retrieving, by the one or more processors, data from theendpoint based on the second API request having the second API format;converting, by the one or more processors, the data from the endpointinto the first format; and transmitting, by the one or more processors,the data from the endpoint in the first format.

In further examples, the method further includes: identifying, by theone or more processors, an endpoint at which the first API request isdirected; retrieving, by the one or more processors, data from theendpoint based on the second API request having the second API format;and transmitting, by the one or more processors, the data from theendpoint in the second format.

In further examples, identifying the first API format includesreceiving, by the one or more processors, an indication of a source ofthe first API request; and identifying, by the one or more processors,the first API format based on the source of the first API request.

In further examples, the second API format has a different structurethan the first API format and the third API format.

In further examples, generating the second API request includes:parsing, via the configuration file and by the one or more processors,the first API request to identify first one or more parameters;comparing, via the configuration file and by the one or more processors,the first one or more parameters to a data structure, the data structurecomprising a plurality of parameters associated with the second APIformat; and generating, via the configuration file and by the one ormore processors, second one or more parameters associated with thesecond API format based on the comparison of the first one or moreparameters to the data structure.

In further examples, the second API format is one of Extensible MarkupLanguage, Yet another markup language, or JavaScript Object Notation.

In further examples, the first API request includes authenticationinformation in the first format, and wherein the second API requestcomprises the authentication information in the second format.

In further examples, generating the second API request includesobtaining, by the one or more processors, endpoints from which toreceive data by recursively applying, by the one or more processors, thefirst API request to the first configuration file.

In further examples, recursively applying the first API request to thefirst configuration file includes: obtaining variables indicatingendpoints to specify in an API request by applying the first API requestto the first configuration; and applying the first API request to thefirst configuration file for a second time but with the obtainedvariables indicating the endpoints.

In further examples, generating the second API request includes:parsing, via the configuration file by the one or more processors, thefirst API request to identify first one or more parameters; comparing,via the configuration file by the one or more processors, the first oneor more parameters to a data structure, the data structure comprising aplurality of parameters associated with the second API format; anddetermining, via the configuration file by the one or more processors,second one or more parameters of the first one or more parameters thatdo not correspond to a parameter of the plurality of parameters based onthe comparison of the first one or more parameters. In such furtherexamples, the method further includes: generating, by the one or moreprocessors, an alert indicating that the second one or more parameterscould not be transformed into the second format; and displaying, by theone or more processors, the alert on a user interface.

In further examples, the method further includes: receiving, by the oneor more processors, a fifth API request having a fifth format;comparing, by the one or more processors, an identification of the fifthformat to a database; determining, by the one or more processors, thatthere is not a configuration file associated with the fifth format basedon the comparison of the identification of the fifth format to thedatabase; generating, by the one or more processors, an alert indicatingthat there is not a configuration file associated with the fifth format;and displaying, by the one or more processors, the alert on a userinterface.

In further examples, the first API request includes authenticationinformation appended to the first API request, and the authenticationinformation is transmitted to an endpoint without being converted toanother format.

In further examples, generating the second API request includesgenerating an array having values from a plurality of locations of anendpoint.

Further examples relate to a system for application program interface(API) request conversion, where the system includes one or moreprocessors and memory coupled to the one or more processors and storinginstructions that, when executed by the one or more processors, causethe one or more processors to: generate a plurality of configurationfiles, each configuration file associated with a different API format;receive a first API request; identify a first API format of the firstAPI request; identify a first configuration file of the plurality ofconfiguration files based on the first API format; generate a second APIrequest having a second API format by applying the first API request tothe first configuration file; receive a third API request; identify athird API format of the third API request; identify a secondconfiguration file of the plurality of configuration files based on thethird API format; and generate a fourth API request having the secondAPI format by applying the third API request to the second configurationfile to generate a fourth API request having the second API format.

In further examples of the system, the instructions, when executed,further cause the processor to: identify endpoint at which the first APIrequest is directed; retrieve data from the endpoint based on the secondAPI request having the second API format; convert the data from theendpoint into the first format; and transmit the data from the endpointin the first format.

In further examples of the system, the instructions, when executed,further cause the processor to: identify an endpoint at which the firstAPI request is directed; retrieve data from the endpoint based on thesecond API request having the second API format; and transmit the datafrom the endpoint in the second format.

In further examples of the system, the instructions, when executed,cause the processor to identify the first API format: receiving anindication of a source of the first API request; and identifying thefirst API format based on the source of the first API request.

In further examples of the system, the second API format has a differentstructure than the first API format and the third API format.

In further examples of the system, generating the second API requestincludes: parsing, via the configuration file, the first API request toidentify first one or more parameters; comparing, via the configurationfile, the first one or more parameters to a data structure, the datastructure comprising a plurality of parameters associated with thesecond API format; and generating, via the configuration file, secondone or more parameters associated with the second API format based onthe comparison of the first one or more parameters to the datastructure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computing device, according to somearrangements.

FIG. 2 is a block diagram depicting an example API request conversionsequence, according to some arrangements.

FIG. 3 is a block diagram depicting an API conversion system, accordingto some arrangements.

FIG. 4 is a flow diagram of a method for generating API requests with acommon format, according to some arrangements.

FIG. 5 is a flow diagram of a method performed using a configurationfile for converting an API request having one format to an API requesthaving a common format, according to some arrangements.

DETAILED DESCRIPTION

Hereinafter, example implementations will be described in more detailwith reference to the accompanying drawings, in which like referencenumbers refer to like elements throughout. The present disclosure,however, can be embodied in various different forms, and should not beconstrued as being limited to only the illustrated examples herein.Rather, these examples are provided as examples so that this disclosurewill be thorough and complete, and will fully convey the aspects andfeatures of the present disclosure to those skilled in the art.Accordingly, processes, elements, and techniques that are not necessaryto those having ordinary skill in the art for a complete understandingof the aspects and features of the present disclosure cannot bedescribed. Unless otherwise noted, like reference numerals denote likeelements throughout the attached drawings and the written description.

As software “eats the world,” the technological landscape is evergrowing, forking, fragmenting, and recombining. While this growthprovides users and developers alike with a plethora of choices when itcomes to how and when to interface with new systems, the inevitableoutcome of this growth is interoperability issues and difficulty ofintegration. This is because different APIs use different syntaxes,codes, and so on for the same functions, requests, jobs, commands, etc.

The common language/interface for integrating modern web-based systemmay be the application programming interface (API). Unfortunately, eachproduct/service has its own unique API that is constantly evolving andchanging. If one is interested in integrating with another system's API,one may have to constantly update their own to understand changes in theintegrated system's API. This may cause “code rot” where code ceases towork due to its dependencies changing over time. This issue may befamiliar to any developer who has maintained an integrated project for aprolonged period of time.

As disclosed, by implementing the proposed systems and methods describedherein, API structures may be abstracted or converted into correspondingconfiguration files. Such configuration files may be used to extractdata from API requests and generate API requests in any format that anoperator chooses without managing any underlying complexities of theunderlying communication between different API. That is, the systems andmethods disclosed herein can convert API requests originating fromdifferent APIs into a uniform API format for a client system to consume,so that the operator of the client system does not need to manage thecomplexities of the different API formats.

Computing Device

Referring now to FIG. 1, a block diagram of a computing device 100 isshown, according to some arrangements. The computing device 100 may beuseful for practicing one or more arrangements of the presentdisclosure. As shown in FIG. 1, in some arrangements, the computingdevice 100 includes a central processing unit 102, a main memory unit104, a storage device 106, an installation device 108, a networkinterface 110, an input/output (I/O) controller 112, one or more displaydevices 114 (e.g., 114 a-114 n), a keyboard 116, and a pointing device118 (e.g., a mouse). The storage device 106 may include, withoutlimitation, an operating system (OS) 122, software 124, and a softwareinstance of an API conversion platform (or tool). The computing device100 may also include additional optional elements, for example, such asa memory port, a bridge, one or more input/output devices 120 (e.g., 120a-120 n), and cache memory in communication with the central processingunit 102.

In some arrangements, the central processing unit 102 may be anysuitable logic circuitry that responds to and processes instructionsfetched from the main memory unit 104. In some arrangements, the centralprocessing unit 102 is provided by a microprocessor unit. For example,in some arrangements, the microprocessor unit may include one or moremicroprocessors manufactured by Intel Corporation of Mountain View,Calif., Motorola Corporation of Schaumburg, Ill., the ARM processor andTEGRA system on a chip (SoC) manufactured by Nvidia of Santa Clara,Calif., the POWER7 processor, those manufactured by InternationalBusiness Machines of White Plains, N.Y., and/or by Advanced MicroDevices of Sunnyvale, Calif. The computing device 100 may be based onany of these processors, or any other suitable processor capable ofoperating as described herein. In various arrangements, the centralprocessing unit 102 may utilize instruction level parallelism, threadlevel parallelism, different levels of cache, and/or multi-coreprocessors. A multi-core processor may include two or more processingunits on a single computing component. Examples of a multi-coreprocessors include the AMD PHENOM IIX2, INTEL CORE i5 and INTEL CORE i7.

In some arrangements, the main memory unit 104 may include one or morememory chips capable of storing data and allowing any storage locationto be directly accessed by the central processing unit 102. In somearrangements, the main memory unit 104 may be volatile and faster thanthe storage device 106. In various arrangements, the main memory unit104 may be Dynamic random access memory (DRAM) or any variants,including static random access memory (SRAM), Burst SRAM or SynchBurstSRAM (BSRAM), Fast Page Mode DRAM (FPM DRAM), Enhanced DRAM (EDRAM),Extended Data Output RAM (EDO RAM), Extended Data Output DRAM (EDODRAM), Burst Extended Data Output DRAM (BEDO DRAM), Single Data RateSynchronous DRAM (SDR SDRAM), Double Data Rate SDRAM (DDR SDRAM), DirectRambus DRAM (DRDRAM), and/or Extreme Data Rate DRAM (XDR DRAM). In somearrangements, the main memory 104 or the storage device 106 may benon-volatile memory, for example, such as non-volatile read accessmemory (NVRAM), flash memory non-volatile static RAM (nvSRAM),Ferroelectric RAM (FeRAM), Magnetoresistive RAM (MRAM), Phase-changememory (PRAM), conductive-bridging RAM (CBRAM),Silicon-Oxide-Nitride-Oxide-Silicon (SONOS), Resistive RAM (RRAM),Racetrack, Nano-RAM (NRAM), and/or Millipede memory. The main memory 104may be based on any of the above described memory chips, or any otheravailable memory chips capable of operating as described herein. In somearrangements, the central processing unit 102 communicates with the mainmemory unit 104 via a system bus 128 (described in more detail below).In other arrangements, the central processing unit 102 may communicatedirectly with the main memory unit 104 via a memory port.

In some arrangements, the central processing unit 102 may communicatedirectly with cache memory via a secondary bus, sometimes referred to asa backside bus. In other arrangements, the central processing unit 102may communicate with cache memory using the system bus 128. Cache memorytypically has a faster response time than the main memory unit 104, andis typically provided by SRAM, BSRAM, or EDRAM. In some arrangements,the central processing unit 102 communicates with various I/O devices120 via a local system bus (e.g., the system bus 128). Various buses maybe used to connect the central processing unit 102 to any of the I/Odevices 120, including a PCI bus, a PCI-X bus, or a PCI-Express bus, ora NuBus. In arrangements in which the I/O devices 120 include a videodisplay device 114, the central processing unit 102 may use an AdvancedGraphics Port (AGP) to communicate with the display device 114 or theI/O controller 112 for the display device 114.

In various arrangements, a wide variety of I/O devices 120 a-120 n maybe included in the computing device 100. For example, in variousarrangements, the input devices of the I/O devices 120 a-120 n mayinclude keyboards, mice, trackpads, trackballs, touchpads, touch mice,multi-touch touchpads and touch mice, microphones, multi-arraymicrophones, drawing tablets, cameras, single-lens reflex camera (SLR),digital SLR (DSLR), CMOS sensors, accelerometers, infrared opticalsensors, pressure sensors, magnetometer sensors, angular rate sensors,depth sensors, proximity sensors, ambient light sensors, gyroscopicsensors, and/or other sensors. In various arrangements, the outputdevices of the I/O devices 120 a-120 n may include, for example, videodisplays, graphical displays, speakers, headphones, inkjet printers,laser printers, and/or 3D printers.

In some arrangements, I/O devices 120 a-120 n may include a combinationof multiple input or output devices, such as, for example, MicrosoftKINECT, Nintendo Wiimote for the WII, Nintendo WII U GAMEPAD, AppleIPHONE, Android based smart phones, and/or the like. In somearrangements, some of the I/O devices 120 a-120 n may allow gesturerecognition inputs through a combination of some of the inputs andoutputs. In some arrangements, some of the I/O devices 120 a-120 n mayprovide for facial recognition, which may be utilized as an input fordifferent purposes including authentication and other commands. In somearrangements, some of the I/O devices 120 a-120 n may provide for voicerecognition and inputs, such as, for example, Microsoft KINECT, SIRI forIPHONE by Apple, Google Now or Google Voice Search, and/or the like.

In some arrangements, addition I/O devices 120 a-120 n may have bothinput and output capabilities, including, for example, haptic feedbackdevices, touchscreen displays, multi-touch displays, and/or the like.Touchscreen, multi-touch displays, touchpads, touch mice, or other touchsensing devices may use different technologies to sense touch,including, for example, capacitive, surface capacitive, projectedcapacitive touch (PCT), in-cell capacitive, resistive, infrared,waveguide, dispersive signal touch (DST), in-cell optical, surfaceacoustic wave (SAW), bending wave touch (BWT), force-based sensingtechnologies, and/or the like. Some multi-touch devices may allow two ormore contact points with the surface, allowing advanced functionalityincluding, for example, pinch, spread, rotate, scroll, and/or othergestures. Some touchscreen devices, including, for example, MicrosoftPIXELSENSE and Multi-Touch Collaboration Wall, may have larger surfaces,such as on a table-top or on a wall, and may also interact with otherelectronic devices. In some arrangements, some of the I/O devices 120a-120 n, display devices 114 a-114 n, or group of devices may be augmentreality devices. In some arrangements, the I/O devices (e.g., keyboard116, pointing device 118, display devices 114, and/or I/O devices 120)may be controlled by the I/O controller 112. In some arrangements, anI/O device may also provide storage and/or an installation medium (e.g.,installation device 108) for the computing device 100. In still otherarrangements, the computing device 100 may provide USB connections toreceive handheld USB storage devices. In further arrangements, an I/Odevice 120 may be a bridge between the system bus 128 and an externalcommunication bus, for example, such as a USB bus, a SCSI bus, aFireWire bus, an Ethernet bus, a Gigabit Ethernet bus, a Fibre Channelbus, a Thunderbolt bus, and/or the like.

In some arrangements, the display devices 114 a-114 n may be connectedto the I/O controller 112. In various arrangements, the display devices114 a-114 n may include, for example, a liquid crystal display (LCD), athin film transistor LCD (TFT-LCD), a blue phase LCD, an electronicpapers (e-ink) display, a flexible display, a light emitting diodedisplay (LED), a digital light processing (DLP) display, a liquidcrystal on silicon (LCOS) display, an organic light-emitting diode(OLED) display, an active-matrix organic light-emitting diode (AMOLED)display, a liquid crystal laser display, a time-multiplexed opticalshutter (TMOS) display, a 3D or stereoscopic display, and/or the like.Examples of 3D displays may include, for example, stereoscopy,polarization filters, active shutters, autostereoscopy, and/or the like.Display devices 114 a-114 n may also include a head-mounted display(HMD). In some arrangements, display devices 114 a-114 n or thecorresponding I/O controllers 112 may be controlled through or havehardware support for OPENGL, DIRECTX API, and/or other graphicslibraries.

In some arrangements, the computing device 100 may include or connect tomultiple display devices 114 a-114 n, which each may be of the same ordifferent type and/or form. As such, any of the I/O devices 120 a-120 nand/or the I/O controller 112 may include any type and/or form ofsuitable hardware, software, or combination of hardware and software tosupport, enable or provide for the connection and use of multipledisplay devices 114 a-114 n by the computing device 100. For example,the computing device 100 may include any type and/or form of videoadapter, video card, driver, and/or library to interface, communicate,connect or otherwise use the display devices 114 a-114 n. In onearrangement, a video adapter may include multiple connectors tointerface to multiple display devices 114 a-114 n. In otherarrangements, the computing device 100 may include multiple videoadapters, with each video adapter connected to one or more of thedisplay devices 114 a-114 n. In some arrangements, any portion of theoperating system 122 of the computing device 100 may be configured forusing multiple displays 114 a-114 n. In other arrangements, one or moreof the display devices 114 a-114 n may be provided by one or more othercomputing devices connected to the computing device 100, via a network.In some arrangements software may be designed and constructed to useanother computer's display device as a second display device 114 a forthe computing device 100. For example, in one arrangement, an Apple iPadmay connect to a computing device 100 and use the display of thecomputing device 100 as an additional display screen that may be used asan extended desktop. One of ordinarily skill in the art will recognizeand appreciate the various ways and arrangements that a computing device100 may be configured to have multiple display devices 114 a-114 n.

In some arrangements, the storage device 106 (e.g. one or more hard diskdrives or redundant arrays of independent disks) may store the operatingsystem 122, and/or other related software, and may store applicationsoftware programs such as any program related to the software instanceof the API conversion platform 126. Examples of the storage device 106may include hard disk drive (HDD), optical drive including CD drive, DVDdrive, and/or BLU-RAY drive, solid-state drive (SSD), USB flash drive,and/or any other suitable device for storing data. Some storage devices106 may include multiple volatile and non-volatile memories, such as,for example, solid state hybrid drives that combine hard disks withsolid state cache. Some storage devices 106 may include non-volatile,mutable, and/or read-only. Some storage devices 106 may be internal andmay connect to the computing device 100 via the bus 128. Some storagedevices 106 may be external and may be connect to the computing device100 via an I/O device 120 that provides an external bus. Some storagedevices 106 may connect to the computing device 100 via the networkinterface 110 over a network, such as, for example, the Remote Disk forMACBOOK AIR by Apple. Some computing devices 100 may not require anon-volatile storage device 106 and may be thin clients or zero clients.Some storage devices 106 may also be used as an installation device 108,and may be suitable for installing software and programs. Additionally,the operating system and the software can be run from a bootable medium,for example, such as a bootable CD (e.g. KNOPPIX), which may be abootable CD for GNU/Linux that is available as a GNU/Linux distributionfrom knoppix.net.

In some arrangements, the computing device 100 may also install softwareor application from an application distribution platform. Examples ofapplication distribution platforms include the App Store for iOSprovided by Apple, Inc., the Mac App Store provided by Apple, Inc.,GOOGLE PLAY for Android OS provided by Google Inc., Chrome Webstore forCHROME OS provided by Google Inc., and Amazon Appstore for Android OSand KINDLE FIRE provided by Amazon.com, Inc. An application distributionplatform may facilitate installation of software on the computing device100. An application distribution platform may include a repository ofapplications on a server or a cloud, which the computing device 100 mayaccess over a network (e.g., the Internet). An application distributionplatform may include application developed and provided by variousdevelopers. A user of the computing device 100 may select, purchase,and/or download an application via the application distributionplatform.

In some arrangements, the computing device 100 may include the networkinterface 110 to interface to a network through a variety of connectionsincluding, but not limited to, for example, standard telephone lines LANor WAN links (e.g., 802.11, T1, T3, Gigabit Ethernet, Infiniband),broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet,Ethernet-over-SONET, ADSL, VDSL, BPON, GPON, fiber optical includingFiOS), wireless connections, and/or some combination of any or all ofthe above. Connections can be established using a variety ofcommunication protocols (e.g., TCP/IP, Ethernet, ARCNET, SONET, SDH,Fiber Distributed Data Interface (FDDI), IEEE 802.11/b/g/n/ac CDMA, GSM,WiMax and direct asynchronous connections). In one arrangement, thecomputing device 100 communicates with other computing devices via anytype and/or form of gateway or tunneling protocol (e.g. Secure SocketLayer (SSL) or Transport Layer Security (TLS), or the Citrix GatewayProtocol manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Fla.).In some arrangements, the network interface 110 may include, forexample, a built-in network adapter, network interface card, PCMCIAnetwork card, EXPRESSCARD network card, card bus network adapter,wireless network adapter, USB network adapter, modem, and/or any othersuitable device for interfacing the computing device 100 to any type ofnetwork capable of communication and performing the operations describedherein.

In some arrangements, the computing device 100 may operate under thecontrol of the operating system 122, which controls scheduling of tasksand access to system resources. In various arrangements, the computingdevice 100 may run any suitable operating system 122, such as, forexample, any of the versions of the MICROSOFT WINDOWS operating systems,the different releases of the Unix and Linux operating systems, anyversion of the MAC OS for Macintosh computers, any embedded operatingsystem, any real-time operating system, any open source operatingsystem, any proprietary operating system, any operating systems formobile computing devices, and/or any other suitable operating systemcapable of running on the computing device 100 and performing theoperations described herein. Some examples of operating systems 122include, but are not limited to: WINDOWS 2000, WINDOWS Server 2012,WINDOWS CE, WINDOWS Phone, WINDOWS XP, WINDOWS VISTA, WINDOWS 7, WINDOWSRT, WINDOWS 8, WINDOWS 10, and/or the like, all of which aremanufactured by Microsoft Corporation of Redmond, Wash.; MAC OS and iOS,manufactured by Apple, Inc. of Cupertino, Calif.; Linux, afreely-available operating system, e.g. Linux Mint distribution(“distro”) or Ubuntu, distributed by Canonical Ltd. of London, UnitedKingdom; Unix or other Unix-like derivative operating systems; andAndroid, designed by Google, of Mountain View, Calif., but may includeothers. Some operating systems 122, including, for example, the CHROMEOS by Google, may be used on zero clients or thin clients (e.g.,CHROMEBOOKS).

In various arrangements, the computing device 100 can be anyworkstation, telephone, desktop computer, laptop or notebook computer,netbook, ULTRABOOK, tablet, server, handheld computer, mobile telephone,smartphone or other portable telecommunications device, media playingdevice, a gaming system, mobile computing device, and/or any othersuitable type and/or form of computing, telecommunications, or mediadevice that is capable of communication. The computing device 100 hassufficient processor power and memory capacity to perform the operationsdescribed herein. In some arrangements, the computing device 100 mayhave different processors, operating systems, and input devicesconsistent with the device.

In some arrangements, the computing device 100 may be a gaming system.For example, the computing device 100 may include a PLAYSTATION (1, 2,3, 4, and/or the like), a PERSONAL PLAYSTATION PORTABLE (PSP), and/or aPLAYSTATION VITA device manufactured by the Sony Corporation of Tokyo,Japan, a NINTENDO DS, NINTENDO 3DS, NINTENDO WII, NINTENDO WII U, and/orNintendo Switch device manufactured by Nintendo Co., Ltd., of Kyoto,Japan, an XBOX 360, XBOX one, and/or the like manufactured by theMicrosoft Corporation of Redmond, Wash., and/or the like.

In some arrangements, the computing device 100 may be a digital audioplayer such as the Apple IPOD, IPOD Touch, and IPOD NANO lines ofdevices, manufactured by Apple Computer of Cupertino, Calif. Somedigital audio players may have other functionality, including, forexample, a gaming system or any functionality made available by anapplication from a digital application distribution platform. Forexample, the IPOD Touch may access the Apple App Store. In somearrangements, the computing device 100 is a portable media player ordigital audio player supporting file formats including, but not limitedto, MP3, WAV, M4A/AAC, WMA Protected AAC, AIFF, Audible audiobook, AppleLossless audio file formats and .mov, .m4v, and/or .mp4 MPEG-4(H.264/MPEG-4 AVC) video file formats.

In some arrangements, the computing device 100 may be a tablet, forexample, such as the IPAD line of devices by Apple; GALAXY TAB family ofdevices by Samsung; KINDLE FIRE, by Amazon.com, Inc. of Seattle, Wash.;and/or the like. In other arrangements, the computing device 100 may bea eBook reader, such as, for example, the KINDLE family of devices byAmazon.com, or the NOOK family of devices by Barnes & Noble, Inc. of NewYork City, N.Y.

While some non-limiting examples of various computing devices 100 andcomponents thereof have been described herein, the present disclosure isnot limited to these examples. For example, other suitable computingdevices and/or components thereof relating to one or more of the variousaspects of the operating environments and components described above inthe context of the systems and methods disclosed herein arecontemplated, as will be apparent to those having ordinary skill in theart.

API Conversion Platform

Referring now to FIG. 2, a block diagram depicting an example APIrequest conversion sequence 200 is shown, according to somearrangements. The API request conversion sequence 200 is shown toinclude systems 202 a-202 n making corresponding API requests 204 a-204n to obtain information from a system 214 (e.g., a server providing andmaintaining webpages). Systems 202 a-202 n may send API requests 204a-204 n in varying formats based on the APIs that the respective ones ofthe system 202 a-202 n use to generate the request. For example, thesystem 202 a may use an API from a software development kit (SDK) torequest information about a webpage that is maintained by system 214. Inone example, the API from the SDK of the system 202 a may generate APIrequest 204 a in an XML format. The system 202 b may use an API fromanother SDK to request information about another webpage that ismaintained by the system 214. The API of the system 202 b may generatethe API request 204 b in a JSON format. The system 202 n may use an APIfrom yet another SDK to request information about a third webpage thatis maintained by the system 214. The API of the system 202 n maygenerate the API request 204 n in a BSON format. Each of the APIrequests 204 a-204 n may be transmitted to an API conversion platform126. The API requests 204 a-204 n may each be in any format. The APIconversion platform 126 may receive the API requests 204 a-204 n andgenerate new API requests 212 a-212 n in a common (same) format such asbut not limited to, YAML, to transmit to the system 214. As such, eachof the API requests 212 a-212 n may have the same format. This allowsthe system 214 to consume API requests in a single format instead ofdealing with the API requests 204 a-204 n in different formats (e.g.,formats A, B, and C).

Each of the systems 202 a-202 n may be any system that can make requeststo obtain information from system 214. The systems 202 a-202 n may beassociated with different entities from each other and/or from thesystem 214 or be a part of the same entity. As described herein, anentity may be a computer processor, server, company, person,application, or an any other entity that may have an API to send andreceive API requests. For example, each of the systems 202 a-202 n andthe system 214 may be any type of computing component (e.g., a server,processor, mobile phone, tablet, laptop, personal computer, etc.). Insome arrangements, each of the systems 202 a-202 n may be similar to thecomputing device 100, shown and described with reference to FIG. 1. Insome arrangements, each of the systems 202 a-202 n is a part of the sameentity. For example, the system 202 a may be a browser being executed bya processor of a computer while the system 214 may be an applicationexecuted by the same processor that generates a user interface for agame. In another example, the system 202 b may be a browser and thesystem 214 may be or be associated with a remote database (e.g., adatabase stored by a third party). The systems 202 a-202 n may send theAPI requests 204 a-202 n to the system 214 via APIs that are specific tothe respective ones of the systems 202 a-202 n.

Each API request may include one or more parameters. A parameter is atype of data that is being requested in an API request. For example, anAPI request may ask for a number of users that used a website on aspecific date (e.g., January 1^(st)). The parameter in the request wouldbe the number of users. APIs may include any number of parameters intheir requests and the parameters may be of any data type.

Each API of the systems 202 a-202 n may send API requests with APIformats that are specific to the API (although one or more API formatsmay be common across various APIs of different ones of the systems 202a-202 n). An API format may be the format in which data in the bodyand/or the header of an API request is positioned and any words,symbols, or phrases that are used to make such API requests. Each APIformat may differ in its structure, wording, or syntax. Examples of APIformats include, but are not limited to, JSON, BSON, YAML, XML, and soon. An example body of an API request in JSON may be the following:

{ “Name”: “”, “Address”: “”, “Phone Number”: “” }In this example API request, the API is requesting the name, address,and phone number of a person from an endpoint. Each of the name,address, and phone number may be a parameter. The request may be sent toan API of the endpoint (e.g., an entity that store the API that receivesthe request and in some cases, that store data for the for the API toretrieve) to be processed. An example body of an API request for thesame parameters in XML, may be the following:

<tsRequest> <Name: “”>, <Address: “”> <Phone Number”: “”> <tsRequest>While example API formats are presented herein for illustrativepurposes, the API formats may take any form and request any information.

Different APIs can read and write in different API formats. For example,when generating an API request, an API may indicate, in a header of therequest, the API format of the body of the request. Consequently, theAPI that receives the request can identify the API format of the requestand determine whether it can read or write in the same format. In somearrangements, the request may also include an indication of the APIformat in which it would like to receive the response. In somearrangements, an administrator may identify the API format of therequest. As described below, the API conversion platform 126 mayidentify which format each of the API requests 204 a-204 n is in (eitherbased on an administrator input or from the header), identify aconfiguration file corresponding to the API format, and apply the APIrequest to the configuration file to generate a new request (e.g., oneof the requests 212 a-212 n) that is readable by the API to which theAPI request is directed (e.g., to the API of the endpoint of therequest).

The API conversion platform 126 may be a software program executed onthe computing device 100, shown and described with reference to FIG. 1.In some arrangements, the API conversion platform 126 may be hosted on acloud computing platform including one or more controllers, servers,and/or any other suitable computing devices that can be accessed by thecomputing device 100 over a network (e.g., the Internet) via the networkinterface 110. The API conversion platform 126 may be an interfacingsoftware program that enables APIs that send requests in any format tocommunicate with an API on the system 214 that does not necessarily havethe capability to communicate in the same format. For example, in somearrangements, the API conversion platform 126 may receive API requestsin one or more of XML, YAML, JSON, and so on and generate new requestsrequesting the same data in a new format that the API on the system 214can read and process. The API conversion platform 126 may also enablethe API on the computing device 100 to respond to the request so therequesting API may read the response.

For example, the API conversion platform 126 may include a fileidentifier 208, a configuration file 209, a request generator 210, and aresponse generator 211. The file identifier 208 may be a softwareprogram executed on the computing device 100, shown and described withreference to FIG. 1. The file identifier 208 may include programmedinstruction to receive API requests and identify the format of the APIrequests from their headers. The file identifier 208 may determinewhether the API request may be converted into an API request to which anAPI of the system 214 may read and respond by comparing the identifiedformat of the API request to configuration files stored in the APIconversion platform 126. If the file identifier 208 can identify aconfiguration file corresponding to the format of an API request, thefile identifier 208 may apply the API request to the correspondingconfiguration file so the request generator 210 can generate a new APIrequest in the API format that is readable to the API of system 214.

The configuration file 209 may be a software program executed on thecomputing device, shown and described with reference to FIG. 1. Theconfiguration file 209 may include programmed instructions and representan example configuration file that can receive API requests in oneformat and generate arrays requesting the same parameters as the APIrequests but in a new format that the API of the system 214 may read.The configuration file 209 may generate the arrays in the new format byidentifying the requested parameters in the original API request anddetermine how the parameters would be requested in the new format. Insome arrangements, the configuration file 209 may be used to determinehow the parameters would be requested in the new format by comparing therequest to a data structure that stores corresponding parameters in thenew format. The configuration file 209 may identify matching parameterrequests and generate new parameter requests in the new format. Therequest generator 210 may identify the parameter requests in the newformat and generate a new API request in the new format. The requestgenerator 210 may transmit the new request to the system 214 to obtainthe requested information.

The response generator 211 may be a software program executed on thecomputing device, shown and described with reference to FIG. 1. Theresponse generator 211 may include programmed instructions to obtain therequested information from the endpoint and generate a response in aformat that the requesting API can understand. In some arrangements, theresponse generator 211 may format the response in a format that therequesting API requested in the header of the API request. In somearrangements, the response generator 211 may generate the response basedon the format in which the requesting API made the request. Once theresponse generator 211 generates the response, the response generator211 may transmit the response to the requesting API.

Referring now to FIG. 3, a block diagram depicting a detailed APIconversion platform 126 is shown, according to some arrangements. TheAPI conversion platform 126 is shown to include a format identifier 304,a file identifier 306, a configuration file database 308, anauthenticator 324, a paginator 326, an error generator 328 and a requestgenerator 330. The API conversion platform 126 may be configured toreceive an API request. The API request may be in any format. The APIconversion platform 126 may identify the format of the API request andselect a configuration file based on the identified format. The APIconversion platform 126 may apply the API request to the configurationfile to generate a new API request for the same information that the APIrequest is directed including any authentication, endpoint, and/orpaging information, and transmit the generated API request to the sameAPI to which the original API request was directed. The API conversionplatform 126 may receive a response including the requested informationand format the response in a format that the requesting API canunderstand. The API conversion platform 126 may transmit the responseback to the requesting API.

The format identifier 304 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Theformat identifier 304 may include programmed instructions to receive anyAPI requests that are transmitted to a system in which the APIconversion platform 126 is implemented (e.g., the system 214, shown anddescribed with reference to FIG. 2) and identify the formats of therequests. In some arrangements, the format identifier 304 may identifythe formats by parsing the headers of the API requests. The API requestheaders (such as in POST requests) may indicate which format the body ofthe requests are in. An example header of an API request may include thefollowing:

-   -   Content-Type: text/xml        In this example header, the API request indicates that the body        of the request is in an XML API format. The format identifier        304 may identify the API format of the API request as XML from        the header. The format identifier 304 may identify the format of        API requests for any API format. In some arrangements, an        administrator may provide an input indicating the format of the        API request. The format identifier 304 may identify the API        formats of API requests based on the administrator inputs.

In some arrangements, the format identifier 304 may identify the APIthat sent the request and the format of the API requests. In sucharrangements, once the format identifier 304 identifies which format therequest was in, the format identifier 304 may associate the API with theidentified format and identify the format of any future API requeststhat the same API sends based on the API sending the request instead ofbased on the header of the request. Once the format identifier 304identifies the format of the API request, the file identifier 306 mayidentify a configuration file corresponding (mapped) to the API request.

The file identifier 306 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Thefile identifier 306 may include programmed instructions to identify theformat of API requests that are identified by the format identifier 304and identify a corresponding configuration file in the configurationfile database 308. The file identifier 306 may identify thecorresponding configuration file in the configuration file database 308by comparing the identified format of the API request to theconfiguration file database 308. Each configuration file in theconfiguration file database 308 may be tagged with an indicatorindicating the format with which the configuration file is associated.In response to the file identifier 306 determining that it is unable toidentify a matching configuration file, the error generator 328 maygenerate an error indicating that no matching configuration file couldbe found and present the error at a user interface of the computingdevice making the API request. On the other hand, in response to thefile identifier 306 determining that it is able to identify a matchingconfiguration file, the file identifier 306 may select the configurationfile and apply the matching API request to the selected configurationfile to generate a new request.

The configuration file database 308 can be a dynamic database includingdata inputs that the configuration file database 308 receives. Theconfiguration file database 308 can be a graph database, MySQL, Oracle,Microsoft SQL, PostgreSql, DB2, document store, search engine, key-valuestore, etc. The configuration file database 308 may be configured tohold any amount of data and can be made up of any number of components,in some arrangements. In some arrangements, the configuration filedatabase 308 is a cloud database that collects and stores data fromcomputing devices other than the computing device 100. The configurationfile database 308 may be configured to store configuration files for anynumber of API request formats so API requests may be generated in thesame format regardless of the API format of the request. Each of theconfiguration files of the configuration file database 308 may includeprogrammed instructions to generate the new API request. For example, aconfiguration file 310 a is shown to include a request parser 312, aparameter identifier 314, an endpoint identifier 316, a parameterconverter 318, an error identifier 320, and a structure generator 322.Each of these components may operate together to build an API request ina common format for an API of any endpoint. Configuration files mayinclude any number of components to perform the operations of thecomponents 312-322.

The request parser 312 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Therequest parser 312 may include programmed instructions to parse throughAPI requests to identify keywords and/or phrases of the request for thecomponents 314-322 to use to generate an API request. For example, therequest parser 312 may parse through the header and the body of therequest to identify variables, parameters, endpoints, or any otheraspect of the API request that may be necessary to generate acorresponding new API request. The request parser 312 may parse throughAPI requests looking for any words or phrases that indicate that theyfall into any of these categories. The request parser 312 may determineif the words or phrases fall into the categories by comparing the wordsor phrases to a database and identifying matching words or phrases inthe database. In some arrangements, the request parser 312 may determineif the words or phrases fall into the categories based on the syntax ofthe API request. For example, the request parser 312 may be configuredto identify the second word in the body of an API request as a requestfor a parameter. Accordingly, the request parser 312 may identify thesecond word as a parameter and the parameter identifier 314 may identifythe parameter. The request parser 312 may perform any operation toidentify aspects of the API request.

The parameter identifier 314 may be a software program executed on thecomputing device, shown and described with reference to FIG. 1. Theparameter identifier 314 may include programmed instructions to identifyany parameters that an API request is requesting. For example, theparameter identifier 314 may identify any parameters that are includedin an initial API request. The parameter identifier 314 may identifyparameters from the query string, the header, and/or the body of the APIrequest. In some instances, the requested parameters may be variablesthat may vary depending on the endpoint to which the received APIrequest is directed. Such variables may be useful when recursive APIrequests are needed to pull information from an API. For example, anendpoint may store data in different regions that each require differentcalls. An API making a request may not know which region to call in arequest so the API may instead include a variable in the request to befilled in based on the region in which the data is stored. In somearrangements, the parameter identifier 314 may determine the region tomake the request by calling the endpoint and receiving an indication ofthe correct region to make any calls for the variable.

The parameter identifier 314 may also identify authenticationparameters. The parameter identifier 314 may identify authenticationparameters in the header or the body of API requests, depending on wherethe API requests places the authentication parameters. Suchauthentication parameters may be passed to end points to confirm thatthe API has the correct authentication credentials to obtain therequested information. For example, authentication credentials mayinclude a username/password combination, a signature, a public key, orany other authentication information to be verified by the endpoint. Theparameter identifier 314 may identify the authentication parametersbased on the words or syntax of the API request similar to how theparameter identifier 314 identified the other parameters.

In some arrangements, the parameter identifier 314 may identify anypaging information that accompanies API requests. The parameteridentifier 314 may identify the paging information from the header orthe body of the request. The parameter identifier 314 may generate anindication of whether the new API request will require paging. Thisindication can be placed in the body, the header, the query string, orany other part of the new request. The parameter identifier 314 may alsoidentify the name of the data structure in which the paging info can befound. The name of the data structure may be a variable. Multiplevariables may be used to identify data structures for paging. Finally,the parameter identifier 314 may identify where to expect the paginginformation when receiving a response from the API of the endpoint.

The endpoint identifier 316 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Theendpoint identifier 316 may include programmed instructions to identifyendpoints of any API requests that the API conversion platform 126receives. An endpoint is a point in which an API receiving an APIrequest is located. Endpoints may be the location at which any requesteddata is stored. The endpoint identifier 316 may identify endpoints ofAPI requests based on the headers of the API requests. The endpointidentifier 316 may identify the endpoints using the syntax of the APIrequest. For example, the endpoint identifier 316 may be configured toidentify an endpoint based on the last words in a GET request. Anexample GET request is the following:

-   -   GET https://stats.rci.com/food/caloriecounter/        The endpoint identifier 316 may identify the endpoint of the        above request as /food/caloriecounter/. /food/caloriecounter/        may be associated with a server or other computing device as        described herein that stores caloric information about various        food items. The endpoint identifier 316 may identify the        endpoint based on the request. In some arrangements, the        endpoint identifier 316 may identify a region of an endpoint to        call when requesting data from that endpoint. The endpoint        identifier 316 may do so when an endpoint stores data across        multiple entities such as servers and an API making a request        does not know which entity to direct the request. The endpoint        identifier 316 may send a signal to the endpoint asking the        location of the requested data and an API may respond with an        address of the location for future requests. In some        arrangements, the endpoint identifier 316 may identify the        regional endpoints based administrator inputs. the endpoint        identifier 316 may identify endpoints based on any method.

The parameter converter 318 may be a software program executed on thecomputing device, shown and described with reference to FIG. 1. Theparameter converter 318 may include programmed instructions to convertany parameters that are identified in API requests into a new API formatthat is readable by the API to which the API requests are directed. Todo so, the parameter converter 318 may identify any parameters that theparameter identifier 314 identifies. The parameter converter 318 may beconfigured to convert the identified parameters into the correct syntaxof the new API format. For example, the parameter converter 318 mayconvert a parameter in XML format into a parameter in JSON format. Theparameter in XML format may have opening and closing tags indicating theparameter that is being requested in the API request. The parameters inJSON may be set apart by various symbols. The parameter converter 318may convert the format of the requested parameter by generating a newrequest including a request for the same parameter but using name/valuepairs (which are common in the JSON format) that are delineated byvarious symbols such as “{“, ”}”, “[“, ”]”, and “:” in the JSON format.Depending on the configuration file, the parameter converter of theconfiguration file may convert a parameter request in any format to aparameter request in any other format. For instance, parameterconverters may convert requests from XML to JSON (as shown above), fromJSON to XML, from XML to YAML, from YAML to XML, from JSON to YAML, fromYAML to JSON, etc.

The error identifier 320 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Theerror identifier 320 may include programmed instructions to identify anyerrors that occurred when the configuration file 310 was generating anew request in the new format. An error may be an identification that aportion of an API request could not be converted into a new API request.Such errors may occur if the request included a syntax that theconfiguration file 310 could not handle, spelling errors, an improperendpoint identification, improper authentication information, requesteddata could not be found by the endpoint API (i.e., in cases withrecursive calls), or any other errors that may occur when theconfiguration file 310 is generating a new request. The error identifier320 may identify such errors and generate an error to display at a userinterface of the requesting API indicating what the error was and whichdata could not be retrieved based on the API request. The erroridentifier 320 may generate the error by creating an array that includeseach of the errors. The error identifier 320 may generate the array inthe new API format or in a format that the requesting API can otherwiseunderstand to display at its respective computing device.

The structure generator 322 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Thestructure generator 322 may include programmed instructions to use anyidentified parameters (including authentication and paging information),endpoint(s), and/or errors to generate structures for new API requests.The structure generator 322 may identify any converted parameters,endpoints, variables, and any other type of data that were identified orconverted by the parameter identifier 314, the endpoint identifier 316,and/or the parameter converter 318 and generate a new request with adata structure that the API of the endpoint may handle. The datastructure may include parameters in a syntax of a common API format suchas JSON, YAML, XML, or any other API format. In some arrangements, thedata structure may include a syntax that is specific to theconfiguration file. All or a portion of the parameters or other APIrequest information that is included in API requests that the APIconversion platform 126 generates may be generated in a new format inthe new API request that the API of the endpoint may receive andunderstand.

In some instances, the structure generator 322 may include anyauthentication information in the new API request in the header of a newAPI request instead of including it as a parameter in the body of therequest. The structure generator 322 may do so based on the API of theendpoint and how it is configured to authenticate API requests. In thesescenarios, the structure generator 322 may keep the authenticationinformation in the same format that it was in in the original request orgenerate the authentication information in the new API request in thenew format. Accordingly, the structure generator 322 may generate an APIrequest in a new format including similar information to the requestthat the API conversion platform 126 received in the original request.

The authenticator 324 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Theauthenticator 324 may include programmed instructions to determinewhether an API making a request is authorized to make such a request.The authenticator 324 may determine whether the output of theconfiguration file associated with the request includes authorizationparameters. In response to determining that there are not anyauthorization parameters in the output, authenticator may useauthentication parameters of a previous API call to call the API of thesame endpoint. For example, the authenticator 324 may input username andpassword information or key information (depending on the endpoint) tothe new API request if it is not already included in the output of theconfiguration file. Consequently, an API making requests to the sameendpoint may only need to provide authentication information once andthe authenticator 324 may propagate the authentication information intoany future API requests.

The paginator 326 may be a software program executed on the computingdevice 100, shown and described with reference to FIG. 1. The paginator326 may include programmed instructions to determine whether there areany more results of the API request the need to be peeked through. Thepaginator 326 may identify the default number of results from theconfiguration files and determine whether there are any more results ofthe request need to be paged through. In response to the paginator 326determining that there are more results that need to be paged through,the paginator 326 or some other component of the API conversion platform126 may page through the results or request to view the next page of theresults from the API of the endpoint. Otherwise, the response generator332 may proceed to transmit the results of the request to the requestingAPI.

The error generator 328 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Theerror generator 328 may include programmed instructions to identify anyerrors that the configuration file that generated the API requestgenerated. In some arrangements, the error generator 328 may be the samecomponent or be in communication with the error identifier 320. Theerror generator 328 may generate a data structure including any errorinformation that the error identifier 320 of the configuration file 310a identified and/or generated. The error generator 328 may generate thedata structure to be included in the response to the original APIrequest. In some arrangements, the error generator 328 may generate anyerrors that the error identifier 320 identified or generated into aformat that is readable by the requesting API. Such errors may begenerated to be displayed on a user interface of the computing device ofthe requesting API.

The request generator 330 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Therequest generator 330 may include programmed instructions to generate anAPI request based on the parameters and other information that iscollected and otherwise generated by a configuration file of theconfiguration file database 308. The request generator 330 maydynamically build the request by collecting the any parameters that weregenerated by the configuration file and using the collected parametersto set up the header variables that need to be passed, encoding therequest however it needs to be encoded whether it needs to be encoded inURL or some other form of coding (depending on the endpoint), etc. Therequest generator 330 may also include authentication information (e.g.,username and password) in the request including any time values that maybe used for authentication. The request generator 330 may send thegenerated request to the API of the endpoint. The API of the endpointmay generate and transmit a response to the request including therequested information. The response generator 332 may receive theresponse and transmit it to the requesting API.

The response generator 332 may be a software program executed on thecomputing device 100, shown and described with reference to FIG. 1. Theresponse generator 332 may include programmed instructions to make surethe response includes valid information to transmit back to therequesting API. The response generator 332 may check to make sure thatthe API conversion system 126 got a valid result and to make sure thesame request has not been run before adding any information that may beused in future requests (e.g., authentication information that may bestored for future requests) to a data structure of the API conversionplatform 126. The response generator 332 may check to see whether all ofthe requested information is in the response and check for an indicatorof whether the paginator 326 needs to do any paging. In response todetermining that the indicator indicates that paging is necessary toidentify any desired results of the request, the paginator 326 mayrecursively request information from the API of the endpoint until theresponse generator 332 determines that all of the necessary informationhas been included. The Response generator 332 may combine all of thedata that has been paged and make sure the paginator 326 does not needto make any more requests. In response to the response generator 332determining that all of the requested information is a part of theresponse and/or any errors have been added to the response, the responsegenerator 332 may transmit the response to the requesting API.

Referring now to FIG. 4, a flow diagram of a method 400 for generatingAPI requests with a common format is shown, according to somearrangements. The method 400 may be implemented using, or performed by,the components detailed herein in connection with FIGS. 1-3. Referringto FIGS. 1-4, the method 400 may be performed by any of the componentsof the API conversion platform 126 in response to receipt of an APIrequest. The method 400 may be used to receive an API request in oneformat and generate a new API request in a different format that an APIof an endpoint may understand.

At 402, the API conversion platform 126 may generate a plurality ofconfiguration files. A configuration file may be a file that performsoperations on API requests to convert (or generate) the API requestsfrom one format into a second format. While API files may each convertAPI requests into a common API format, each configuration file may onlyconvert API requests in a specific format to the common API format. Forexample, one configuration file may convert an API request from YAML toJSON. Another configuration file may convert an API request from XML toJSON. In some examples, such conversions may be the only conversionsthat each of the configuration files may perform. To perform theconversion, each configuration file may be configured to handle anyparameters, authentication information, paging information, variables,or any other aspect of an API request that is format specific. Eachconfiguration file may identify the aspects of the requests and generatea corresponding data structure that includes the same aspects but in anew API format.

At 404, the API conversion platform 126 may receive a first API request.The API conversion platform 126 may receive the first API request froman API that is on the same computing device or from another computingdevice across a network. The first API request may be directed to an APIof an endpoint to obtain information from the endpoint. At 406, the APIconversion platform 126 may determine whether there a configuration filein a database of the API conversion platform 126 that corresponds to aformat of the first API request. To do so, the API conversion platform126 may identify the format of the first API request (e.g., based on itsheader or on an administrator input) and compare the format to thedatabase that stores configuration files. The API conversion platform126 may identify tags on the configuration files to determine whetherany of them are associated with the same format as the first APIrequest. In response to determining that the API conversion platform 126cannot identify a matching configuration file, at 408, the APIconversion platform 126 may generate an error indicating that nomatching configuration file could be found and transmit the error to therequesting API. In some arrangements, the API conversion platform 126may also transmit the error to the API that was supposed to be thecorrect to inform the API that an attempt to request information fromthe API was made and was unsuccessful.

In response to the API conversion platform 126 identifying a matchingconfiguration file, at 410, the API conversion platform 126 may identifythe configuration file (e.g., a first configuration file) to which thefirst API corresponds (e.g., that is associated with the API format ofthe first API request). At 412, the API conversion platform 126 maygenerate a second API request having a second API format by applying thefirst API request to the corresponding configuration file. The secondformat may be a different format than the first format. For example, thefirst format may be any of JSON, XML, or YAML and the second format be adifferent format of the same group of formats. In some arrangements, thesecond format is an abstract format that is not related to anywell-known API formats but is still readable by an API of the endpoint.Described in more detail below with reference to FIG. 5, theconfiguration file may generate a data structure that the API conversionplatform 126 may use to generate the second API request. The APIconversion platform 126 may generate the second API request based on theendpoint to which it is transmitting the API request (in some instancesthe configuration file may generate a data structure that is specific tothe endpoint as well). For example, the API conversion platform 126 maygenerate the second request to have the authentication parameters,paging information, and any other information that may be uniquelyassociated with the endpoint. After generating the second API request,the API conversion platform 126 may transmit the second API request tothe API of the endpoint.

At 414, the API conversion platform 126 may receive a third API request.The API conversion platform 126 may perform 414 similar to how the APIconversion platform 126 performed 404. At 416, the API conversionplatform 126 may identify a third API format of the third API request416. Although not shown, the API conversion platform 126 may thendetermine whether there is a corresponding configuration file to thethird API format in the database of the API conversion platform 126similar to 406 and perform an operation similar to 408 in response tothere not being a corresponding configuration file in the API conversionplatform 126. In response to determining that a matching configurationfile is identified, at 418, the API conversion platform 126 may identifythe matching configuration file as a second configuration file. The APIconversion platform 126 may perform 418 similar to how the APIconversion platform 126 performed 410. At 420, the API conversionplatform 126 may generate a fourth API request having the second APIformat by applying the third API request to the second configurationfile.

Referring now to FIG. 5, a flow diagram of a method 500 performed by aconfiguration file for converting an API request having a first formatto an API request having a second format is shown, according to somearrangements. The functionalities of the method or process 500 may beimplemented using, or performed by, the components detailed herein inconnection with FIGS. 1-3. For example, method 500 may be performed byany of the configuration files 310 a-310 n of the API conversionplatform 126 in response to receipt of an API request. In briefoverview, method 500 may be used to generate an array of parameters thatare compatible with a second API format that the API of an endpoint mayprocess and, in some cases, an array of parameters that may not beretrieved because of an error in the request.

In more detail, when the API conversion platform 126 receives an APIrequest, the format identifier 304 may identify the format of the APIrequest from its header and the file identifier 306 may identify acorresponding configuration file of the API conversion platform 126 tothe identified format of the API request. In various arrangements, theidentified corresponding configuration file may be a source file, aheader file, a PCH file, a resource file, or the like. The fileidentifier 306 may apply the API request to the identified correspondingconfiguration file (e.g., the configuration file 310 a) to generate anew API request with an API format that is readable to the API thatreceives the request. For example, the method 500 starts, and at 502,the request parser 312 of the configuration file 310 a may parse the APIrequest that was applied to the configuration file 310 a to identify afirst one or more parameters in a first format. The request parser 312may parse through the API request and identify each parameter that isbeing requested in the request. The request parser 312 may identify therequested parameters based on the format of the requested parameters.

For example, a configuration file that is specific to requests that arereceived in the YAML format may be configured with a base keyidentifying how the JSON parameters would be formatted if they wereformatted correctly in the request. The request parser 312 may comparethe words and/or phrases of the API request to this format and identifyany words or phrases that follow the same format. For example, theconfiguration file for YAML requests may identify a current parameter tobe “DescribeInternetGatewayResponse.InternetGatewaySet” because theparameter is correctly formatted as a YAML parameter. In some instances,the current parameter may be an address from which to pull data. At 504,the parameter converter 318 may identify the current parameter andconvert the current parameter to a desired parameter based on thecurrent parameter. Continuing with the example above, the parameterconverter 318 may convert the current parameter above to the desiredparameter of “InternetGateways”. The API of the endpoint may be able toread the desired parameter but may not be able to read the currentparameter based on the formatting of each parameter. In another example,the request parser 312 may identify a current parameter of“items.global.addresses.” The parameter converter 318 may convert thiscurrent parameter to a desired parameter of “Addresses.” Accordingly,when the API request is generated the request may call Addresseslocation of the API instead of items.global.addresses per the API formatin the original request. The request parser 312 and the parameterconverter 318 may identify any base parameters in the request andgenerate any desired parameters.

At 506, the structure generator 322 may generate an array comprising thesecond one or more parameters. The structure generator 322 may generatethe array as the request parser 312 continues to parse through the APIrequest and identify parameters to be converted into the new API formatby the parameter converter 318. The structure generator 322 may identifyany converted parameters, endpoints, variables, or any other type ofdata that was identified or converted by the parameter identifier 314,the endpoint identifier 316, and/or the parameter converter 318 andgenerate a new request with a data structure that the API of theendpoint may handle. The data structure may include a syntax of a commonAPI format such as JSON, YAML, XML, or any other API format. In somearrangements, the data structure may include a syntax that is specificto the configuration file, the API of the endpoint, or the endpointitself. All or a portion of the parameters or other API requestinformation that is included in API requests that the API conversionplatform 126 generates may be generated in a new format in the new APIrequest that the API of the endpoint may receive and understand.

At 508, the error identifier 320 may determine whether there are anyerrors in the API request. The error identifier 320 may determine ifthere are any errors in the API request by determining whether there areany parameters in the API request that could not be converted to a newformat. The error identifier 320 may make such a determination inresponse to the error identifier 320 not being able to identify aparameter in the new API format that corresponds to the parameter in theAPI format of the original API request. The error identifier 320 mayalso identify errors if the original was not formatted correctly or hadincorrect wording or phrasing in one or more portions of the request.The error identifier 320 may identify errors in API requests for anyreason. In response to the error identifier 320 not being able toidentify any errors in the original API request, the process 500 may endand the API conversion system 126 may generate a request using the arraythat the structure generator 322 generated including successfullyconverted parameters.

On the other hand, in response to the error identifier 320 identifyingerrors in the original API request, at 510, the error identifier 320 maygenerate a second array including any parameters that could not beconverted into the second format. The error identifier 320 may generatethe array as parameter converter 318 attempts and fails to convertparameters into the second format for various reasons as describedabove. The error identifier 320 may generate the array in a base formand convert it into a form that is readable by the API to which theoriginal API was requested and/or the API that made the request. Theerror identifier 320 may include any number of errors in the array. Insome arrangements, the error identifier 320 may generate the array so itcan be displayed on a user interface for an operator to see to view anyerrors that occurred including the parameter with which the error isassociated.

The systems and methods described herein may provide for a tool that mayonly require a configuration file specific to an API format to convertor generate an API request with a new format. The systems and methodsprovide for handling of authentication, paging, and other API formatspecific protocols that an API receiving a request in such a format maynot be equipped to understand or respond to. The API request may beuploaded to a configuration file and the configuration file canautomatically generate abstract API requests with formats that differfrom any requests that the API receives but that are readable to theAPIs that receive the requests. Consequently, systems with differentAPIs may more quickly and easily be integrated to communicate with eachother.

The arrangements described herein have been described with reference todrawings. The drawings illustrate certain details of specificarrangements that implement the systems, methods and programs describedherein. However, describing the arrangements with drawings should not beconstrued as imposing on the disclosure any limitations that can bepresent in the drawings.

It should be understood that no claim element herein is to be construedunder the provisions of 35 U.S.C. § 112(f), unless the element isexpressly recited using the phrase “means for.”

As used herein, the term “circuit” can include hardware structured toexecute the functions described herein. In some arrangements, eachrespective “circuit” can include machine-readable media for configuringthe hardware to execute the functions described herein. The circuit canbe embodied as one or more circuitry components including, but notlimited to, processing circuitry, network interfaces, peripheraldevices, input devices, output devices, sensors, etc. In somearrangements, a circuit can take the form of one or more analogcircuits, electronic circuits (e.g., integrated circuits (IC), discretecircuits, system on a chip (SOCs) circuits, etc.), telecommunicationcircuits, hybrid circuits, and any other type of “circuit.” In thisregard, the “circuit” can include any type of component foraccomplishing or facilitating achievement of the operations describedherein. For example, a circuit as described herein can include one ormore transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR,etc.), resistors, multiplexers, registers, capacitors, inductors,diodes, wiring, and so on).

The “circuit” can also include one or more processors communicativelycoupled to one or more memory or memory devices. In this regard, the oneor more processors can execute instructions stored in the memory or canexecute instructions otherwise accessible to the one or more processors.In some arrangements, the one or more processors can be embodied invarious ways. The one or more processors can be constructed in a mannersufficient to perform at least the operations described herein. In somearrangements, the one or more processors can be shared by multiplecircuits (e.g., circuit A and circuit B can comprise or otherwise sharethe same processor which, in some example arrangements, can executeinstructions stored, or otherwise accessed, via different areas ofmemory). Alternatively or additionally, the one or more processors canbe structured to perform or otherwise execute certain operationsindependent of one or more co-processors. In other example arrangements,two or more processors can be coupled via a bus to enable independent,parallel, pipelined, or multi-threaded instruction execution. Eachprocessor can be implemented as one or more general-purpose processors,application specific integrated circuits (ASICs), field programmablegate arrays (FPGAs), digital signal processors (DSPs), or other suitableelectronic data processing components structured to execute instructionsprovided by memory. The one or more processors can take the form of asingle core processor, multi-core processor (e.g., a dual coreprocessor, triple core processor, quad core processor, etc.),microprocessor, etc. In some arrangements, the one or more processorscan be external to the apparatus, for example the one or more processorscan be a remote processor (e.g., a cloud based processor). Alternativelyor additionally, the one or more processors can be internal and/or localto the apparatus. In this regard, a given circuit or components thereofcan be disposed locally (e.g., as part of a local server, a localcomputing system, etc.) or remotely (e.g., as part of a remote serversuch as a cloud based server). To that end, a “circuit” as describedherein can include components that are distributed across one or morelocations.

An exemplary system for implementing the overall system or portions ofthe arrangements might include a general purpose computing computers inthe form of computers, including a processing unit, a system memory, anda system bus that couples various system components including the systemmemory to the processing unit. Each memory device can includenon-transient volatile storage media, non-volatile storage media,non-transitory storage media (e.g., one or more volatile and/ornon-volatile memories), etc. In some arrangements, the non-volatilemedia can take the form of ROM, flash memory (e.g., flash memory such asNAND, 3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, harddiscs, optical discs, etc. In other arrangements, the volatile storagemedia can take the form of RAM, TRAM, ZRAM, etc. Combinations of theabove are also included within the scope of machine-readable media. Inthis regard, machine-executable instructions comprise, for example,instructions and data which cause a general purpose computer, specialpurpose computer, or special purpose processing machines to perform acertain function or group of functions. Each respective memory devicecan be operable to maintain or otherwise store information relating tothe operations performed by one or more associated circuits, includingprocessor instructions and related data (e.g., database components,object code components, script components, etc.), in accordance with theexample arrangements described herein.

It should be noted that although the diagrams herein can show a specificorder and composition of method steps, it is understood that the orderof these steps can differ from what is depicted. For example, two ormore steps can be performed concurrently or with partial concurrence.Also, some method steps that are performed as discrete steps can becombined, steps being performed as a combined step can be separated intodiscrete steps, the sequence of certain processes can be reversed orotherwise varied, and the nature or number of discrete processes can bealtered or varied. The order or sequence of any element or apparatus canbe varied or substituted according to alternative arrangements.Accordingly, all such modifications are intended to be included withinthe scope of the present disclosure as defined in the appended claims.Such variations will depend on the machine-readable media and hardwaresystems chosen and on designer choice. It is understood that all suchvariations are within the scope of the disclosure. Likewise, softwareand web implementations of the present disclosure could be accomplishedwith standard programming techniques with rule based logic and otherlogic to accomplish the various database searching steps, correlationsteps, comparison steps and decision steps.

It is also understood that any reference to an element herein using adesignation such as “first,” “second,” and so forth does not generallylimit the quantity or order of those elements. Rather, thesedesignations can be used herein as, a convenient means of distinguishingbetween two or more elements or instances of an element. Thus, areference to first and second elements does not mean that only twoelements can be employed, or that the first element must precede thesecond element in some manner.

The foregoing description of arrangements has been presented forpurposes of illustration and description. It is not intended to beexhaustive or to limit the disclosure to the precise form disclosed, andmodifications and variations are possible in light of the aboveteachings or can be acquired from this disclosure. The arrangements werechosen and described in order to explain the principals of thedisclosure and its practical application to enable one skilled in theart to utilize the various arrangements and with various modificationsas are suited to the particular use contemplated. Other substitutions,modifications, changes and omissions can be made in the design,operating conditions and arrangement of the arrangements withoutdeparting from the scope of the present disclosure as expressed in theappended claims.

What is claimed is:
 1. A method for application program interface (API)request conversion, comprising: generating, by one or more processors, aplurality of configuration files, each configuration file associatedwith a different API format; receiving, by the one or more processors, afirst API request; identifying, by the one or more processors, a firstAPI format of the first API request; identifying, by the one or moreprocessors, a first configuration file of the plurality of configurationfiles based on the first API format; and generating, by the one or moreprocessors, a second API request having a second API format by applyingthe first API request to the first configuration file.
 2. The method ofclaim 1, further comprising: identifying, by the one or more processors,an endpoint at which the first API request is directed; retrieving, bythe one or more processors, data from the endpoint based on the secondAPI request having the second API format; converting, by the one or moreprocessors, the data from the endpoint into the first format; andtransmitting, by the one or more processors, the data from the endpointin the first format.
 3. The method of claim 1, further comprising:identifying, by the one or more processors, an endpoint at which thefirst API request is directed; retrieving, by the one or moreprocessors, data from the endpoint based on the second API requesthaving the second API format; and transmitting, by the one or moreprocessors, the data from the endpoint in the second format.
 4. Themethod of claim 1, wherein identifying the first API format comprises:receiving, by the one or more processors, an indication of a source ofthe first API request; and identifying, by the one or more processors,the first API format based on the source of the first API request. 5.The method of claim 1, wherein generating the second API requestcomprises: parsing, via the configuration file and by the one or moreprocessors, the first API request to identify first one or moreparameters; comparing, via the configuration file and by the one or moreprocessors, the first one or more parameters to a data structure, thedata structure comprising a plurality of parameters associated with thesecond API format; and generating, via the configuration file and by theone or more processors, second one or more parameters associated withthe second API format based on the comparison of the first one or moreparameters to the data structure.
 6. The method of claim 1, wherein thesecond API format is one of Extensible Markup Language, Yet anothermarkup language, or JavaScript Object Notation.
 7. The method of claim1, wherein the first API request comprises authentication information inthe first format, and wherein the second API request comprises theauthentication information in the second format.
 8. The method of claim1, wherein generating the second API request comprises: obtaining, bythe one or more processors, endpoints from which to receive data byrecursively applying, by the one or more processors, the first APIrequest to the first configuration file.
 9. The method of claim 8,wherein recursively applying the first API request to the firstconfiguration file comprises: obtaining variables indicating endpointsto specify in an API request by applying the first API request to thefirst configuration; and applying the first API request to the firstconfiguration file for a second time but with the obtained variablesindicating the endpoints.
 10. The method of claim 1, further comprising:parsing, via the configuration file by the one or more processors, thefirst API request to identify first one or more parameters; comparing,via the configuration file by the one or more processors, the first oneor more parameters to a data structure, the data structure comprising aplurality of parameters associated with the second API format; anddetermining, via the configuration file by the one or more processors,second one or more parameters of the first one or more parameters thatdo not correspond to a parameter of the plurality of parameters based onthe comparison of the first one or more parameters.
 11. The method ofclaim 1, wherein generating the second API request comprises: parsing,via the configuration file by the one or more processors, the first APIrequest to identify first one or more parameters; comparing, via theconfiguration file by the one or more processors, the first one or moreparameters to a data structure, the data structure comprising aplurality of parameters associated with the second API format; anddetermining, via the configuration file by the one or more processors,second one or more parameters of the first one or more parameters thatdo not correspond to a parameter of the plurality of parameters based onthe comparison of the first one or more parameters; wherein the methodfurther comprises: generating, by the one or more processors, an alertindicating that the second one or more parameters could not betransformed into the second format; and displaying, by the one or moreprocessors, the alert on a user interface.
 12. The method of claim 1,further comprising: receiving, by the one or more processors, a fifthAPI request having a fifth format; comparing, by the one or moreprocessors, an identification of the fifth format to a database;determining, by the one or more processors, that there is not aconfiguration file associated with the fifth format based on thecomparison of the identification of the fifth format to the database;generating, by the one or more processors, an alert indicating thatthere is not a configuration file associated with the fifth format; anddisplaying, by the one or more processors, the alert on a userinterface.
 13. The method of claim 1, wherein the first API requestcomprises authentication information appended to the first API request,and wherein the authentication information is transmitted to an endpointwithout being converted to another format.
 14. The method of claim 1,wherein generating the second API request comprises generating an arraycomprising values from a plurality of locations of an endpoint.
 15. Asystem for application program interface (API) request conversion, thesystem comprising: one or more processors; and memory coupled to the oneor more processors and storing instructions that, when executed by theone or more processors, cause the one or more processors to: generate aplurality of configuration files, each configuration file associatedwith a different API format; receive a first API request; identify afirst API format of the first API request; identify a firstconfiguration file of the plurality of configuration files based on thefirst API format; and generate a second API request having a second APIformat by applying the first API request to the first configurationfile.
 16. The system of claim 15, wherein the instructions, whenexecuted, further cause the processor to: identify an endpoint at whichthe first API request is directed; retrieve data from the endpoint basedon the second API request having the second API format; convert the datafrom the endpoint into the first format; and transmit the data from theendpoint in the first format.
 17. The system of claim 15, wherein theinstructions, when executed, further cause the processor to: identify anendpoint at which the first API request is directed; retrieve data fromthe endpoint based on the second API request having the second APIformat; and transmit the data from the endpoint in the second format.18. The system of claim 15, wherein the instructions, when executed,cause the processor to identify the first API format: receiving anindication of a source of the first API request; and identifying thefirst API format based on the source of the first API request.
 19. Thesystem of claim 15, wherein the second API format has a differentstructure than the first API format.
 20. The system of claim 15, whereingenerating the second API request comprises: parsing, via theconfiguration file, the first API request to identify first one or moreparameters; comparing, via the configuration file, the first one or moreparameters to a data structure, the data structure comprising aplurality of parameters associated with the second API format; andgenerating, via the configuration file, second one or more parametersassociated with the second API format based on the comparison of thefirst one or more parameters to the data structure.